Collaborative Workspace - Team Development Setups |
|
Setting up an application development environment where multiple developers come together to develop applications has its own needs and challenges. Through Collaborative Workspace (CWS), Process Platform offers an application development environment where several developers can work together on the same software deliverable.
CWS accommodates all the requirements of team application development. It provides a single interface at design time to develop the application content. It facilitates easy creation and modification of the documents that form the building blocks of an application. All developers developing an application can access their own workspace through a browser on any computer and work simultaneously on the same application content.
The following scenarios are the most probable options in which you can set up Process Platform development teams in CWS to collaboratively develop an application:
- Separate Developer Stations - Configured to a Source Control Management (SCM) system
- Separate Workspaces - Central Development Server - Configured to an SCM system
- Multiple Development Servers - Configured to an SCM system
- Single Workspace - Central Development Server
Note: This is an exemplary list of scenarios. There might be more scenarios based on the development requirements.
Separate Development Machines - Configured to an SCM System
In this setup, every developer has Process Platform installed on the individual development machine and has an individual workspace. The workspaces on the different development machines are configured to a common SCM system. Developers can develop content in their local machines. They can either get updates from the SCM system or make their local change set (updated development content) available to the SCM system.
Build or deployment, test, and production activities are carried out on separate servers connected to the same SCM system.
This setup has the following features:
- One development server per developer.
- Isolation of development content.
- Application content is shared with other developers through the SCM system.
- Versions of the developed content are maintained in the SCM system.
- If required, workspaces can be removed without impacting the content stored in the SCM system.
The following illustration may help you understand this type of development setup.
Separate Workspaces - Central Development Server - Configured to an SCM System
In this setup, every developer connects to a private workspace on the central or shared development server. The workspaces on this development server are linked to the same SCM repository. Developers can add and modify content within their respective workspaces. They can either receive updated content from the SCM system or make their change set (updated development content) available to the SCM system through the option available in their workspace.
The build or deployment server receives all the updates from the SCM system. On demand or at regular intervals, the build master incorporates all changes to this workspace and packages all projects. This results in creation of application packages that can be loaded on test or production servers for testing or production respectively.
This setup has the following salient features:
- Every development server supports multiple development workspaces.
- Isolation of development content.
- Application content is shared with other developers through the SCM system.
- Shared workspaces where developers can be a part of more than one workspace. This provision facilitates functional grouping of developers within an organization, for example, all business users can work in one workspace.
- Versions of the developed content are maintained in the SCM system.
- If required, workspaces can be removed without impacting the content stored in the SCM system.
The following illustration might help you understand this type of development setup.
Multiple Development Servers - Configured to an SCM System
In the previous setup, the scenario showed that all developers work on a central development server. Alternatively, it is possible to set up multiple development servers and spread the developers across these servers. The workspaces on the different development servers can still be connected to the same SCM system.
The build and deployment process will then be the same as in the previous setup.
This setup has the following salient features:
- Every development server supports multiple development workspaces.
- Developers can be spread across different development servers. This helps in scaling up the number of developers working on the same project when reaching the limits of a single development server. You can also freely choose the geographical locations of the different development servers. This enables you to minimize the network latency for remote development teams.
- Isolation of development content.
- Application content is shared with other developers through the SCM system.
- Versions of the developed content are maintained in the SCM system.
- If required, workspaces can be removed without impacting the content stored in the SCM system.
If multiple developers work on the same application, but from different development servers, these development servers are advised to run exactly the same version of the software.
The following illustration might help you understand this type of development setup.
Single Workspace - Central Development Server
In this setup, there is the option to let all developers work on a central or shared development server and in the same workspace when they work on the same application. All developers use only a single workspace resulting in collaboration in this single workspace. Collaboration can occur even without configuring the workspace to an SCM system. However, in this setup, it is recommended to configure the workspace to an SCM system to ensure that the availability of the sources is not dependent on the existence of this single workspace. Using the SCM integration also ensures that the sources are version controlled.
Additionally, if all developers work in the same workspace, there is an increased chance of multiple developers working on the same models. If one developer decides to test changes, changes of other developers are likely to be published as well. This makes it very hard for individual developers to determine the impact of their isolated changes.
If the workspace is configured to an SCM system, application building and packaging can be done on a separate build server, and the package can then be delivered to separate test and production servers. If the workspace is not configured to an SCM system, the application must be built from that same workspace either manuallly or automatically. The delivery of the package to test and production servers is then similar to all other setups.
Setting up the CWS Development Environment
The following high-level topics contain information that help you set up the CWS development environment: